COMMENT ⊗   VALID 00006 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	∂06-Apr-81  1939	ATP.HINES at UTEXAS-20 	RLL and theorem proving   
C00005 00003	∂Mailed to ATP.HINES@UTEXAS-20 (CC DBL) 14:07 13-Apr
C00011 00004	∂16-Apr-81  0131	ATP.HINES at UTEXAS-20 	Getting RLL,etc.
C00013 00005	∂Mailed to Hines (CC DBL, DE2)  15:51 24-Apr
C00019 00006	∂01-May-81  1743	ATP.HINES at UTEXAS-20 	daunted, into the fray    
C00020 ENDMK
C⊗;
∂06-Apr-81  1939	ATP.HINES at UTEXAS-20 	RLL and theorem proving   
To: RDG at SU-AI
cc: CSD.LENAT at SU-SCORE


I think that I have finally develop a theorem prover system which will benefit
from being implemented in RLL.  However, only a small kernal of the 
knowledge base's templates have been created.  Other frame types have suggested
themselves and, doubtlessly, eventually even more types will be necessary.

I apologize for having to reask this, but I would like to be able to 
<make>
all frames, not marked as permanent, to disappear upon the end of a 
session.  

Anyway, since I have now finally learned a way to use RLL, I would like
to obtain a copy of it.  I am addressable through the APRANET as
ATP.HINES@UTEXAS20 or at least I been told that I am.

larry hines
-------

∂Mailed to ATP.HINES@UTEXAS-20 (CC DBL) 14:07 13-Apr
Answers, sorta
Larry -
Good to hear from you again.  I hope all is well over in Texas.

To answer your questions:
There are several ways to deal with "ephemeral" units, each with its own
set of complications. 

	Solution 1
Every unit which descends from AnyEphemeral will be wasted at
the end of each session.  This is the method I have used for handling such
temporary entities, as it is the safest and most effective.

These wins are not free, though.  As you might imagine, closing and writing the
networks will be expensive in time.  Furthermore, as these entities are
full-fledged units, creating and initializing each may well take longer
than you'd like.  A speed up of, maybe, a factor of 4 or 5 will come about
by judicious use of macros, but there is simply so much work which has to
take place...

	Solution 2
You could avoid much of the time-to-close-the-KBs expense by storing
all ephemerons in some garbage KB, which is simply CANCELled at the end of
each session, rather than WRITEten.  The problem here is the plethora
of un-updated back-pointers.  (IE other units may still point to a now
destroyed temporary unit, causing grief in many situations.)  Still, if
you could tolerate this, this solution will be the fastest, and least
cautious.

	Solution 3a.
Of course, this is not unsolvable:  If you knew which slots might so connect
temporary with permanent units, you could instruct each such slot to
record each connection made; and then quickly map thru these when ending
a session, removing the soon-to-be-offending links.

This will be time-consuming, both during PUTs and when closing things, but
potentially faster than the time loss implied in Soln 1.

	Solution 3b
Yet another infinitely-conservative possibility, (along the lines suggested
by Soln 2 above) would be to spend
some time at the start of each session, to remove all offensive links from
the existing units.

----
The decision of which of these is most desirable is where it belongs: in
lap of the user.  You the user get to consider what requirements your
task will impose of your system, and build the system accordingly --
ie if you can stand some slop, but prefer your program to be fast,
solution 2 may be best.  On the other hand, you may have some idea for
some intermediary system, incorporating some combination of, say 1 and 2
above.  Great - as soon as you implement it, it'll be incorporated into RLL
for the next user.

Final note: realize you're not fighting RLL here -- only the specifications
of your task.  To permit such flexibility.
RLL never commits itself with respect to temporary units.

-----
Next issue: How to get you on RLL.  This is tricky; as RLL is still 
(to be kind) buggy.  I would have no objection to mailing you a copy
(or actually, permitting you to FTP it), but realize there are many things
which will not work, and there are many remaining holes.

Let me what I can do for you.
	Russ

PS I've sent you (ATP.HINES@UTEXAX) several messages, earlier in the year.
(About your SCORE account, and the RLL bulletin board, ...)
Did any other them get thru?
∂16-Apr-81  0131	ATP.HINES at UTEXAS-20 	Getting RLL,etc.

Greetings Russ,
   All is well.  At least as far as I can tell, it is.

   It's the same with you, I hope.

   Thanks for the advice on "ephemeral" units.  My initial guess is that
solution 2 (i.e. garbage KB) is what I'll use; although, AnyEphemeral units
will probably be required, too.

   I don't have a major preference as to which way (FTPing or mailing)
RLL uses to get here.  If I FTPed RLL it is likely that I would get it
sooner and be easiest on you.  I was wondering how much space RLL takes.  

   About your messages to me in Sept., I did get them all (I think) albeit
belately.  If the RLL bboard is still active, I would like to be on it, if 
that is possible.

   By the way, say hi to the bozos from the texas boy.

					
		
						-- larry
∂Mailed to Hines (CC DBL, DE2)  15:51 24-Apr

Undaunted, into the fray
Glad to see you're still interested.  The current version of RLL is now on
Rand-AI's machine.  (One fringe benefit of consulting there was unlimited
access to that marvelously unloaded machine.)

As usual, RLL is a mere epsilon increment away from respectibility, and
hence releasability.  (I'm now twiddling with MACROs, which, I hope, will
speed up its operations a good order of magnitude.)

Its outward appearance hasn't changed much since last summer; that's
pretty much by conscious design.  It has absorbed a fair number of modules
-- mostly concerned with EURISKO, and encoding information about LISP
functions.

Space...
First, RLL is dependent on CORLL, which takes up a fair amount of space.
You may wish to store a CORLL sysout on some public directory -- not only
does this permit others to use this reasonably well documented, (and
possibly useful) tool, but it also spares you from absorbing the cost of
this disk space.  Anyway, this will consume about 300-400 pages.

Now for RLL:  There are currently several essential KBs, each of which
contains a *.KB file, plus an optional *.. and *.COM pair of files for the
associated LISP functions.  Just in static storage requirements, these
will cost about 600 pages.  Your dynamic storage should be almost this
much again, for the *.PAGE temporary files.  (Note you may not have to
worry about this... In fact, there are only a few cases when it makes any
differences: 
(1) if you're system is as stingy as SCORE, which does not permit you any
storage over your allocation, even for an instant; or (2) if you want to
preserve your state using a SYSOUT, in which case you'll have to store
these "temporary files" from one day to the next.  In the latter case you 
will need not only the 4 to 5 hundred pages for the PAGE files, but an 
additional 300 pages for the actual sysout as well.

The figures above refer only to the nucleus required for RLL to run.  You
may, in addition, want to utilize other existant KBs -- and of course this
will cost you space.  Of course, you will be creating your own "theorem
proving" KBs as well.  I have no real idea how much space this will
require -- except to say that whatever you estimate now, I can state from
experience, will not be enough.

Politics and Policies ...  
I've got no objections to handing over RLL, as it stands now.  There are
some caveats:  As I've mentioned before, it's got its share of bugs and
problems; and I've no yen to fix them twice.  Which leads to problems: who
will maintain your version?  How should I communicate the errors and fixes
found?  Perhaps I could periodically mail over new versions of the nuclear
files -- but that would force you to reconnect the units of your nascent
KBs to these time and again.  That may just amount to running the
"reconnecting" code each time - which is easy to do, if time consuming.

Of course that may not work.  There is a mechanism for sending along
single now-fixed units... maybe that's what I should do?  Comments?  (Now
is a good time for me to resolve this issue, as I've been promising to
release this system for months now...)

The other issue is Stanford.  Nobody here minds releasing the software;
but there seems some worry that you might make a buck on it, and not give
Stanford its share.  Sooo, I got a little form I have to have you fill
out.

Comments, critiques, indications of disgust?
	Russ
∂01-May-81  1743	ATP.HINES at UTEXAS-20 	daunted, into the fray    

Gee, the fray is big.  

Well it seems that at the present time finding the space that RLL needs is 
not going to happen.  At least until out system is augmented by a couple more
disk packs (about four months + delivery delay time from now), I am not going
have a home for RLL.

Gee, even the best laid plans ... .

As I'm sure you know, Doug Lenat will be here Monday so I'll speak to
him on this.  

larry
-------